1. Field of the Invention
The present invention relates to software testing, and more particularly to generating test cases automatically.
2. Description of Related Art
Software development can be a difficult process requiring the investment of significant time and resources. Software tools may be used to assist software development, for example by providing abstractions to represent underlying code or details, or by automating tasks. During the development of a new application and after development completion, the application may be tested to ensure that it functions as desired. However, as development tools enable more complex applications to be built, with interoperating modules, more elaborate and complex testing may be required to verify the operation of the software developed. Lack of adequate testing may lead to loss of reliability or loss of functionality, up to complete inoperability on the part of the application, resulting in wasted time and resources. As with development of applications in any environment or language in general, these issues are relevant to developing and testing Java 2 Enterprise Edition (J2EE) software.
As illustrated in FIG. 1, J2EE applications are based on components, or modules. Modules may be of different types, including Enterprise Java Beans (EJBs), Resource Archives (RARs), and Web Archives (WARs). Each module of an application may be responsible for some resource, functionality, or other element that is a part of the operation of that application. An Enterprise Application Archive (EAR) may constitute a standalone application containing J2EE modules. The modules and the EAR file may be platform-independent Java Archives (JAR). Different modules may be packaged within an EAR file. For example, as shown in FIG. 1, a J2EE application 100 stored as an EAR file may include two modules 110 and 120 stored as JAR files. Each module may include its own elements, as indicated at 111, 112, 121, 122, and 123. An EAR file may be deployed on a J2EE server, executed on the server, and undeployed when it has completed its operation. The server may provide a container for an application or module to operate, which may specify a runtime environment with particular features or settings for security, concurrency, life cycle management, transaction, deployment, naming, and/or other services.
A J2EE module or application may have an associated deployment descriptor, typically expressed in eXtensible Markup Language (XML). For example, J2EE application 100, J2EE client 110, and Enterprise Bean 120 include corresponding deployment descriptors 101, 111, and 121. A deployment descriptor may describe configuration requirements of the deployment of its associated module, such as security mechanisms, transaction attributes, or resource references. For example, an EJB deployment descriptor may identify the EJB interface and class names. The container or server of an application may use the deployment descriptor to configure services or generally parts of the runtime environment for the corresponding module. For example, an EAR file 100 may include a deployment descriptor 101 specifying security attributes applicable to the application and a module 120 within the EAR file may include a deployment descriptor 121 describing the scope of its transactions when invoked by other components 110.
Given the modular characteristics of J2EE, which may also be a feature of other operating or programming environments, testing may involve tests of individual member components as well as entire applications. When checking modules, testing may verify that they accomplish their desired purpose or meet their specifications (e.g., produce correct results) and that they operate properly (e.g., do not crash). Testing done on any one platform or server may be sufficient to reveal failures of modules to meet their specifications. However, testing proper operation can be more difficult as this may be dependent on configuration parameters, such as stored in deployment descriptors, and the interaction with other modules, containers, or servers. Testing an application as a whole, including the relationship between modules, their interoperation, or the interaction with a container or server, may also be difficult for similar and additional reasons. Other issues may add to the testing complexity at the application level; for example, results may depend on the execution order of the modules or passing of messages between modules. As a result, the test coverage desired may be extensive and it may be too difficult for application developers to cover the many potential scenarios.